【脆弱性対応】Amazon Linux 2 の EC2インスタンスへ特定パッチを当てる方法を3つ
想定シナリオ
想定シナリオは以下の通り(某試験文章風)
-----
ある企業がAWS上で Amazon Linux 2 の EC2インスタンスからなるアプリケーションを稼働させています。
新しい社内クラウドセキュリティポリシーに準拠するために、すべてのEC2インスタンスに対して 脆弱性診断ツールが導入されました。 そして、脆弱性診断で指摘された重要度CRITICAL の指摘事項は 必ず対応しないといけないと定められています。
ある日 特定のEC2インスタンスに対して 重要度CRITICAL の脆弱性 (CVE-XXXX-XXXX ※)が検出されました。
セキュリティエンジニアであるあなたは、脆弱性が検知された EC2インスタンスに対して セキュリティパッチを当てる責任があります。 まずは検証環境のEC2インスタンスを使って、 効率よくセキュリティパッチを当てる方法を探しはじめました。
※CVE … 共通脆弱性識別子(Common Vulnerabilities and Exposures)
[方法1] SSH or SSM Session Manager で実施
前提条件
対象のEC2インスタンスへ SSHもしくは SSM Session Manager接続ができることが前提です。
※Session Manager 接続がうまくいかない場合は、以下ドキュメントを参考ください。
- ステップ 1: Session Manager の前提条件を満たす - AWS Systems Manager
- 【初心者向け】Session Manager でインスタンスが表示されない時のトラブルシュート | DevelopersIO
パッチを当てる
対象のインスタンスへ接続します。
まず、今回解決したい脆弱性の情報 CVE-XXXX-XXXX の情報を確認します。
yum updateinfo list --cves CVE-2021-3156 # Loaded plugins: extras_suggestions, langpacks, priorities, update-motd # ALAS2-2021-1590 important/Sec. sudo-1.8.23-4.amzn2.2.1.x86_64 # updateinfo list done
脆弱性情報の詳細は yum updateinfo all で確認できます。
yum updateinfo all --cves CVE-2021-3156 # Loaded plugins: extras_suggestions, langpacks, priorities, update-motd # # =============================================================================== # Amazon Linux 2 2017.12 - ALAS2-2021-1590: important priority package update for sudo # =============================================================================== # Update ID : ALAS2-2021-1590 # Release : # Type : security # Status : final # Issued : 2021-01-25 23:09 # Updated : 2021-01-26 18:48 CVEs : CVE-2021-3156 # Description : Package updates are available for Amazon Linux 2 that fix the # : following vulnerabilities: CVE-2021-3156: # : # : 99999: # Severity : important # Installed : false # updateinfo info done
確認後 yum update を使って該当CVEのパッチ当て対応を行います。
sudo yum update --cves CVE-2021-3156 # Loaded plugins: extras_suggestions, langpacks, priorities, update-motd # (略) # Dependencies Resolved # # ============================================================================================================================= # Package Arch Version Repository Size # ============================================================================================================================= # Updating: # sudo x86_64 1.8.23-10.amzn2.1 amzn2-core 846 k # # Transaction Summary # ============================================================================================================================= # Upgrade 1 Package # # (略) # # Updated: # sudo.x86_64 0:1.8.23-10.amzn2.1 # # Complete!
パッチ当て後の確認をします。(今回は sudo の脆弱性対応なのでバージョン出力と、脆弱性有無の判断コマンドを実施)
sudo -V # Sudo version 1.8.23 # Sudoers policy plugin version 1.8.23 # Sudoers file grammar version 46 # Sudoers I/O plugin version 1.8.23 sudoedit -s / # usage: sudoedit (略)
バージョンが変わったこと、脆弱性が無くなっていること確認できました。
[方法2] SSM Run Command で実施
前提条件
SSM Session Manager と同じように、EC2インスタンスをSSM管理下にしておく必要があります。
パッチを当てる
今回は CVE-2021-28038 を解消します。
yum updateinfo list --cves CVE-2021-28038 # Loaded plugins: extras_suggestions, langpacks, priorities, update-motd # ALAS2-2021-1616 important/Sec. kernel-4.14.225-168.357.amzn2.x86_64 # updateinfo list done
[AWS Systems Manager > Run Command] で Run Commandの画面に行き、コマンド実行 [Run Command] を選択します。
コマンドドキュメントは AWS-RunShellScript を選択します。
コマンドのパラメータには以下のような yum update コマンドを入れましょう。
sudo yum update --cves CVE-2021-28038 -y
今回はインスタンスIDの手動指定で実施します。 ※インスタンスタグによる指摘も可能。複数インスタンスの管理で役立ちます
今回はログ出力は無し、他オプションはデフォルトで [実行] します。
しばらく待って、成功すると以下のような画面になります。
コンソールから該当CVEの脆弱性対応が完了していることも確認できました。
yum updateinfo list --cves CVE-2021-28038 # Loaded plugins: extras_suggestions, langpacks, priorities, update-motd # updateinfo list done
AWS CLIから実施
SSM Run Command を CLIから実施できます。 ssm send-command を使います。
CVE=CVE-2019-9924 InstanceID=i-0119xxxxxxxx aws ssm send-command --document-name "AWS-RunShellScript" --document-version "1" \ --instance-ids $InstanceID \ --parameters commands="sudo yum update --cves $CVE -y"
[方法3] SSM Patch Manager で実施
SSM Patch Manager は EC2インスタンスへのパッチ当てのプロセスを 自動化 するための機能です。 「パッチ適用状況のスキャン」もしくは「パッチインストール」の 自動化 に 役立つ機能です。
カスタムパッチベースラインを作ることで 「特定のパッケージはパッチ適用する/パッチ適用しない」といった 柔軟な自動化ルールを作る事ができます。
詳細は以下参照ください。
また、本シナリオのようにオンデマンドにパッチを当てることも可能です。 以下 ブログでそれを行っているのでぜひ参考ください。
まとめ
それぞれのメリット/デメリットを主観でまとめます。
▼ SSH or SSM Session Manager
- メリット
- とりあえず始められる
- 動作や挙動、影響範囲を一番簡単に把握できる
- デメリット
- 効率的ではない
▼ SSM Run Command
- メリット
- コンソール接続せずに実行できる
- 複数インスタンスへ一括でパッチを投入できる
- デメリット
- 自動化はできない
▼ SSM Patch Manager
- メリット
- パッチ当てを自動化(定期実行)できる
- カスタムルールを使って柔軟なパッチ適用ルールを設定できる
- デメリット
- 自動パッチ適用によるアプリケーションへの影響 を考慮する必要がある
- 自動化のリスクが許容できない環境では使用が難しい
SSM Run Command は複数インスタンスへ一括でコマンドを流せるので、効率化のメリットがあります。 ぜひ活用しましょう。
SSM Patch Manager は自動化できるメリットが大きいですが、アプリケーションへの影響をちゃんと考える必要があります。 何も考えずに本番環境へデフォルトベースラインを適用するのは危険です。 検証環境などで試して、どのパッチを適用する/適用しないといったルールを定められるのであれば検討しましょう。
参考
- 【小ネタ】 Amazon Linux の yum update で複数のパッケージ適用 | DevelopersIO
- Yumのセキュリティプラグイン | DevelopersIO
- Linuxで脆弱性が見つかった場合の対応方法 まとめ | DevelopersIO
- IT 担当者ならみんな読みたい！！ セキュリティ情報サイト5選 | DevelopersIO
- Systems Manager Patch Manager で特定パッチを適用する | DevelopersIO
- EC2パッチ運用(Linux) をSystems Managerで実現する | DevelopersIO
- 【AWS Systems Manager】パッチマネージャー実行時の関連リソースを、絵で見て（完全に）理解する。 | DevelopersIO
